Reputation-based strategy for forwarding and responding to interests over a content centric network

ABSTRACT

A CCN network node use reputation values for one or more interfaces to determine how to forward an Interest. During operation, the network node can receive an Interest or Content Object via a network interface, determines one or more candidate outbound faces for forwarding the Interest by performing a longest-prefix-matching lookup in a forwarding information base (FIB) using the Interest&#39;s name or name prefix as input. A respective FIB entry maps a name prefix to a forwarding rule that includes a corresponding outbound face for the name prefix. The node can determine a reputation value for each of the candidate outbound faces based on reputation information stored in association with the Interest&#39;s name or name prefix, and selects a candidate outbound face with a reputation value exceeding a first predetermined threshold. The node can then forward the received Interest via the selected outbound face.

PRIORITY DATA

This is a continuation patent application of (and claims the benefit ofpriority under 35 U.S.C. § 120) of U.S. application Ser. No. 14/335,806,filed Jul. 18, 2014, entitled “REPUTATION-BASED STRATEGY FOR FORWARDINGAND RESPONDING TO INTERESTS OVER A CONTENT CENTRIC NETWORK,” byinventors Priya Mahadevan, et al. The disclosure of the priorapplication is considered part of and is incorporated by reference inthe disclosure of this application in its entirety.

FIELD

The present disclosure generally relates to a content centric network(CCN). More specifically, the present disclosure relates to a method andapparatus for using a reputation-based strategy to forward Interests andreturn Content Objects in a CCN.

RELATED ART

The proliferation of the Internet and e-commerce continues to fuelrevolutionary changes in the network industry. Today, a significantnumber of information exchanges, from online movie streaming to dailynews delivery, retail sales, and instant messaging, are conductedonline. An increasing number of Internet applications are also becomingmobile. However, the current Internet operates on a largelylocation-based addressing scheme. The most ubiquitous protocol, theInternet Protocol (IP), is based on location-based address. That is, aconsumer of content can only receive the content by explicitlyrequesting the content from an address (e.g., IP address) closelyassociated with a physical object or location. This restrictiveaddressing scheme is becoming progressively inadequate for meeting theever-changing network demands.

Recently, content centric networking (CCN) architectures have beenproposed in the industry. CCN brings a new approach to contenttransport. Instead of having network traffic viewed at the applicationlevel as end-to-end connections over which content travels, content isrequested or returned based on its unique name, and the network isresponsible for routing content from the provider to the consumer.

With content centric networks, a node in the network may receive arequest for some content using the content name, which is called anInterest. If the node cannot provide the content to satisfy theInterest, it may forward the Interest through an interface associatedwith the Interest's name or name prefix, and the Interest eventuallyreaches a node that can provide a Content Object to satisfy theInterest.

However, current techniques for forwarding an Interest do not allow forforwarding strategies that may use network resources more efficiently.Network conditions may change and nodes are limited in their ability toadapt and respond to the changing conditions. For example, the responsetime for an interface may increase dramatically, but the node maycontinue to forward Interests to the interface, which is undesirable. Asanother example, the network may become congested at the same time everyday, and certain interfaces may provide a greater bandwidth than others.To make matters worse, some interfaces may deliver content objects whosesignatures do not have a high probability of being verifiedsuccessfully. Current CCN nodes are not capable of selecting whichinterfaces to use for sending or receiving packets to maximizing theirperformance and/or to obtain content from the most reliablenodes/caches.

SUMMARY

One embodiment of the present invention provides a CCN network node thatfacilitates strategic use of reputation values to forward Interests andcache Content Objects. During operation, the network node can determineone or more candidate outbound faces for forwarding an Interest bylooking up the Interest's name or name prefix in a forwardinginformation base (FIB). A respective FIB entry maps a name prefix to aforwarding rule that includes a corresponding outbound face for the nameprefix. The node can determine a reputation value for each of thecandidate outbound faces based on reputation information stored inassociation with the Interest's name or name prefix, and selects acandidate outbound face with a reputation value exceeding a firstpredetermined threshold. The node can then forward the received Interestvia the selected outbound face.

In one variation on this embodiment, the reputation information includesat least one of: a reputation value, a set of attribute values, and aset of attribute weights.

In one variation on this embodiment, the network node determines thereputation value by obtaining the reputation value from the reputationinformation, computing the reputation value based on one or more of theattribute values and attribute weights from the reputation informationor computing the reputation value from one or more of the attributevalues of the reputation information and custom attribute weights forthe one or more attribute values.

In one variation on this embodiment, the node can receive, via one ormore faces, one or more Content Objects associated with a common name orname prefix. The node determines, for each of the one or more ContentObjects, reputation information for a respective face, or for the nameor name prefix of the Content Object received via the respective face.The node then determines whether to cache a respective Content Objectbased on the corresponding reputation information. The node may cachethe Content Object with the corresponding reputation information in aContent Store in response to determining to cache the respective ContentObject.

In one variation on this embodiment, the node can forward the receivedInterest via multiple outbound faces. The node can wait for apredetermined period of time to receive one or more Content Objects viaany of the multiple outbound faces, such that each of the one or moreContent Objects is associated with reputation information. The nodeselects, from the one or more Content Objects, a second Content Objectwith a highest reputation value. The network node may cache the secondContent Object and return the second Content Object via a face fromwhich the Interest was received, in response to determining that thesecond Content Object's reputation value is higher than the reputationvalue of a cached Content Object.

In one variation on this embodiment, the network node can receive asecond Interest from a first ingress face, and perform a lookup in aContent Store to retrieve a cached Content Object that satisfies thesecond Interest. The Content Store may store the Content Object alongwith corresponding reputation information. The network node can returnthe cached Content Object to the requesting node in response todetermining, from the Content Object's reputation information, that theContent Object's reputation value exceeds a predetermined threshold.

In one variation on this embodiment, the network node can assign anattribute value to one or more attributes for a second candidateoutbound face, and assigns a weight value to each of the one or moreattributes. The node can compute a reputation value for the secondcandidate outbound face for the name prefix based on the assignedattribute value and the assigned weight value. The node may storereputation information, which includes the reputation values, attributevalues, and weight values, in association with the candidate outboundface and/or the name prefix.

In one variation on this embodiment, the network node can compute one ormore attribute values for a respective candidate outbound face based onthe name prefix, and can normalize a respective attribute value based ona highest expected value for the attribute. The node can determine aweight for the respective attribute value, and computes the reputationvalue for the outbound face and name prefix as a weighted sum of the oneor more attribute values.

In one variation on this embodiment, the network node can receive afirst Interest from a first ingress face, and a second Interface from asecond ingress face. The network node determines whether the secondingress face is associated with a higher priority than the first ingressface. If so, the network node forwards the first Interest via a firstegress face, and forwards the second Interest via a second egress facewith a reputation value that is higher than that of the first egressface.

In one variation on this embodiment, the network node can determine aset of name prefixes associated with the name prefix classification fora name prefix classification. The network node generates reputationinformation for the name prefix classification based on profilinginformation associated with the set of name prefixes, and associates thereputation information with the name prefix classification.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 presents a diagram illustrating an exemplary network environmentthat includes a CCN, in accordance with an embodiment of the presentinvention.

FIG. 2 presents an exemplary CCN topology that facilitates strategic useof reputation values to forward Interests and cache Content Objects, inaccordance with an embodiment of the present invention.

FIG. 3 presents a flow chart illustrating an overview of an exemplaryprocess for computing a reputation value, in accordance with anembodiment of the present invention.

FIG. 4 presents a flow chart illustrating an exemplary process forreturning a Content Object in response to receiving an Interest, inaccordance with an embodiment of the present invention.

FIG. 5 presents a flow chart illustrating an exemplary process for usingreputation values to determine how to forward an Interest, in accordancewith an embodiment of the present invention.

FIG. 6 presents a flow chart illustrating an exemplary process forupdating attribute values, weight values, and reputation values, andusing reputation values to determine whether to cache a Content Object,in accordance with an embodiment of the present invention.

FIG. 7 presents a block diagram illustrating an exemplary forwardinginformation base (FIB) with reputation values, according to anembodiment.

FIG. 8 presents a block diagram illustrating an exemplary Content Store,according to an embodiment.

FIG. 9 illustrates an exemplary apparatus that facilitates strategicforwarding and caching using reputation values, in accordance with anembodiment.

FIG. 10 presents an exemplary computer system for using reputationvalues to facilitate strategic forwarding and caching, in accordancewith an embodiment of the present invention.

In the figures, like reference numerals refer to the same figureelements.

DETAILED DESCRIPTION

The following description is presented to enable any person skilled inthe art to make and use the invention, and is provided in the context ofa particular application and its requirements. Various modifications tothe disclosed embodiments will be readily apparent to those skilled inthe art, and the general principles defined herein may be applied toother embodiments and applications without departing from the spirit andscope of the present invention. Thus, the present invention is notlimited to the embodiments shown, but is to be accorded the widest scopeconsistent with the principles and features disclosed herein.

The data structures and code described in this detailed description aretypically stored on a computer-readable storage medium, which may be anydevice or medium that can store code and/or data for use by a computersystem. The computer-readable storage medium includes, but is notlimited to, volatile memory, non-volatile memory, magnetic and opticalstorage devices such as disk drives, magnetic tape, CDs (compact discs),DVDs (digital versatile discs or digital video discs), or other mediacapable of storing computer-readable media now known or later developed.

Overview

Embodiments of the present invention solve the problem of inflexible andinefficient utilization of network resources by using reputation valuesto dynamically adapt the forwarding of Interests and caching of ContentObjects. This increases the likelihood of meeting specific objectivesassociated with name prefixes. A CCN node computes a reputation value asa numeric value using a customized calculation designed to weighquantifiable factors that could assist the node to meet specificobjectives. These factors can be quantified by numeric attributes suchas the latency or bandwidth of an interface for a particular nameprefix, or the success rate for verifying Content Object signatures fora particular name prefix coming from an interface. An attribute is aquantifiable property, policy, or characteristic that a node can measureto make an informed decision.

A system administrator can assign a weighted value to each attribute sothat the computed reputation value achieves a desired objective. Theobjectives can include, for example, providing a continuousvideo-streaming experience to a user, or providing authentic data thathas not been forged or tampered with. An objective is typicallyassociated with a specific namespace, and different namespaces may beassociated with different objectives. To achieve the objective,attributes specific to this objective can be used to compute areputation value directed to this objective. Hence, a network node mayassign weight values to an interface's attributes based on an Interest'sname prefix, or based on an objective associated with the name prefix.

By introducing reputation values into the decision-making process at theCCN node, the node can greatly increase the probability of meetingvarious objectives for a namespace. The node has more fine-grainedcontrol and can make more informed decisions when utilizing reputationvalues. The node will more efficiently use network resources andsignificantly reduce the likelihood of content requesters receiving badcontent or poor service.

The node may use a reputation value, for example, to make forwardingdecisions, to decide whether to cache a Content Object, or to determinewhether to return a Content Object read from a cache. The node maycompute a reputation value for each face that it can use to forward anInterest, and forward an Interest to one or more faces with reputationvalues exceeding a predetermined minimum threshold. Note that the term“face” refers to an interface or a virtual interface, and a virtualinterface can include a collection of interfaces. The node may alsocompute a reputation value for a Content Object received from a face,and then cache the Content Object in the Content Store if the reputationvalue exceeds a predetermined threshold. Furthermore, the node mayreturn a Content Object from the Content Store to a requesting node ifthe reputation value associated with the cached Content Object exceeds apredetermined threshold.

In some embodiments, the node may compute a reputation value R which isa linear combination of weighted attribute values <x₁, x₂, . . . ,x_(n)>:

$R = {\sum\limits_{i = 1}^{n}\;{w_{i}x_{i}}}$

where n is the number of attributes, x, is the attribute value forattribute i, and w_(i) is the weight value for attribute i. Attributescan cover a wide variety of topics. Attributes can include performancemetrics such as latency or bandwidth measures for a face. Other examplesof attributes include the number of times that a node has successfullyverified signatures for Content Objects for a particular face, routingpolicies (e.g., restrictions on time of routing or type of networktraffic), and a number of times the node received the same Interest. Thenode may associate different weight values with different attributes toemphasize the importance of certain attributes for a given objectiveassociated with the name prefix, and to reduce the importance of otherattributes. For a given name prefix, a node and/or an administrator mayselect and adjust the attributes and weight values over time to achievean objective of the name prefix.

The node can automatically adapt to changing network conditions to meetobjectives through proper selection and use of attributes and weightvalues in computing the reputation value. For example, by adding alatency attribute to a reputation value and heavily weighting thelatency attribute, a node can forward Interests so that the face withthe lowest latency will receive the Interest, even as the network loadshifts among the faces.

Content-Centric Network Architecture

In a CCN, communication is driven by the consumers of data. The CCNarchitecture provides two packet types: an Interest packet and a ContentObject (e.g., data) packet. An Interest packet (also called a “query”)serves as a request for some content. An Interest packet encodes aspecial form of query that expresses the name (or sometimes name prefix)of the content that is desired. A Content Object packet includes a unitof content. Content Object packets are self-identifying by carryingwithin them their full name. A consumer asks for content by sending theInterest over the content centric network, and any recipient of theInterest can satisfy the Interest by responding with a matching ContentObject. Content Objects are transmitted only in response to an Interest,and consumes that Interest. Both Interest and Content Objects identifythe content being exchanged by the content name (or CCN name). In someembodiments, a Content Object can “satisfy” an Interest if the CCN namein the Interest packet is a prefix of the CCN name in the ContentObject. The following terms describe elements of a content-centricnetwork (CCN):

Content Object: A single piece of named data, which is bound to a uniquename. Content Objects are “persistent,” which means that a ContentObject can move around within a computing device, or across differentcomputing devices, but does not change. If any component of the ContentObject changes, the entity that made the change creates a new ContentObject that includes the updated content, and binds the new ContentObject to a new unique name.

Name: A name in a CCN is typically location independent and uniquelyidentifies a Content Object. A data-forwarding device can use the nameor name prefix to forward an Interest packet toward a network node thatgenerates or stores the Content Object, regardless of a network addressor physical location for the Content Object. In some embodiments, thename may be a hierarchically structured variable-length identifier(HSVLI). The HSVLI can be divided into several hierarchical components,which can be structured in various ways. For example, the individualname components parc, home, ccn, and test.txt can be structured in aleft-oriented prefix-major fashion to form the name“/parc/home/ccn/test.txt.” Thus, the name “/parc/home/ccn” can be a“parent” or “prefix” of “/parc/home/ccn/test.txt.” Additional componentscan be used to distinguish between different versions of the contentitem, such as a collaborative document.

In some embodiments, the name can include a non-hierarchical identifier,such as a hash value that is derived from the Content Object's data(e.g., a checksum value) and/or from elements of the Content Object'sname. A description of a hash-based name is described in U.S. patentapplication Ser. No. 13/847,814 (entitled “ORDERED-ELEMENT NAMING FORNAME-BASED PACKET FORWARDING,” by inventor Ignacio Solis, filed 20 Mar.2013), which is hereby incorporated by reference. A name can also be aflat label. Hereinafter, “name” is used to refer to any name for a pieceof data in a named-data network, such as a hierarchical name or nameprefix, a flat name, a fixed-length name, an arbitrary-length name, or alabel (e.g., a Multiprotocol Label Switching (MPLS) label).

Interest: A packet that indicates a request for a piece of data, andincludes a name (or a name prefix) for the piece of data. A dataconsumer can disseminate a request or Interest across aninformation-centric network, which CCN routers can propagate toward astorage device (e.g., a cache server) or a data producer that canprovide the requested data to satisfy the request or Interest.

A description of a CCN architecture is described in U.S. patentapplication Ser. No. 12/338,175 (entitled “CONTROLLING THE SPREAD OFINTERESTS AND CONTENT IN A CONTENT CENTRIC NETWORK,” by inventors Van L.Jacobson and Diana K. Smetters, filed 18 Dec. 2008), which is herebyincorporated by reference.

Exemplary Architecture of a CCN

FIG. 1 presents a diagram illustrating an exemplary network environmentthat includes a CCN 100, in accordance with an embodiment of the presentinvention. CCN 100 includes a number of devices, such as a laptopcomputer 102, a media server 104, and smartphones 106-111, coupled toeach other via CCN 100. Note that the devices can be any type of acomputing device, including mobile computing devices, such as a laptopcomputer, a tablet or slate computer, a smartphone, or a personaldigital assistant (PDA), or a stationary computing device, such as adesktop computer or a home media server.

In addition, each device may have a reputation computation module, apending interest table (PIT), a forwarding information base (FIB), and aforwarder, among other components. An example of the components isillustrated for media server 104, including a reputation computationmodule 112, a PIT 114, a FIB 116, a forwarder 118, and a Content Store120.

Reputation computation module 112 can compute and update reputationvalues either periodically or on-demand (in near real-time). Node 104maintains PIT 114 to keep track of pending Interests, and can update PIT114 when it receives a new Interest or when a pending Interest issatisfied or times out. PIT 114 stores entries for Interests that are tobe matched against incoming Content Objects, and each entry is onlyremoved when a match is made, or when an Interest times out. FIB 116 isa forwarding table that contains information for node 104 to determineto which neighbor node or nodes an Interest should be sent.

Forwarder 118 forwards Interests and/or packets on the network.Forwarder 118 performs functions that include deciding to which faces itwill forward an Interest based on reputation values, and updatingreputation values and attribute values when a node receives an Interestor a Content Object. Note that in some embodiments, the media server 104may include additional modules that perform some of the individualfunctions of forwarder 118, and embodiments of the present invention arenot limited to the modules described herein.

Content Store 120 can cache Content Objects that media center 104 hasreceived via one or more faces.

Exemplary CCN Topology

FIG. 2 presents an exemplary CCN topology for a set of CCN nodes thatuse reputation values to forward Interests and cache Content Objects, inaccordance with an embodiment of the present invention. FIG. 2illustrates six example nodes 202-212 in a CCN, with five nodes 204-212connected through faces 214-222 to node 202. Node 202 may include, forexample, media server 104 in FIG. 1. Node 202 may receive an Interestthrough face 222, at which point node 202 decides whether to return acached Content Object or forward the Interest.

If there is a Content Object that satisfies the Interest cached inContent Store 120 at node 202, node 202 may return the Content Object ifa reputation value associated with the cached Content Object exceeds apredetermined threshold.

If node 202 determines that it is necessary to forward the Interest,node 202 may use reputation values of faces 214-220 to select faces forforwarding the Interest. Node 202 may send the Interest to a face withthe highest reputation value or send the Interest to a selection offaces with reputation values above a predetermined threshold. Node 202may also use reputation values to determine whether to cache any ContentObject received from its neighboring nodes.

Node 202 can initially assign a set of attributes to a name prefix, orto a face for a particular name prefix. For example, node 202 can assigna set of attributes to name prefix “/bbc.” The first attribute cancorrespond to the frequency that Content Objects containing the nameprefix are requested, and the second attribute can correspond to specialpolicies associated with the name prefix. Hence, computing a reputationvalue for the name prefix (e.g., without an associated face) can beuseful in deciding whether to cache a content object.

In some embodiments, node 202 can compute a reputation value for aninterface, for example, by collapsing reputation values associated withmultiple name prefixes. Computing a reputation value for the interface(e.g., without an associated name prefix) can be useful in deciding howto forward an Interest with a rare name prefix. It may be difficult forthe node to compute an accurate reputation for a name prefix for whichhistorical performance data does not exist, hence the node can decidehow to forward the Interest based on a face's general performance.

Node 202 can also assign a set of attributes to a face for a particularname prefix (e.g., “per name-prefix, per face”). For example, node 202can assign a set of attributes to face 216 for name prefix “/bbc.” Theseattributes can include a latency (e.g., response time in receiving aContent Object after sending an Interest via face 216), and a signatureverification success rate. A Content Object includes a name, data, and asignature that binds the name and data to a producer of the data. Thissignature can confirm the authenticity and integrity of the data.Another attribute can correspond to a routing policy that can specifyrouting constraints or routing considerations, such as restrictions onrouting between nodes during certain time periods or restrictions on thetraffic load or types of traffic to some portions of the network.

An attribute can also involve a protocol for a particular type oftraffic packet, such as video traffic packets. For example, node 202 mayneed to apply certain rules to video traffic packets, and may need toforward the packets to a particular face. Node 202 can map an attributeto a numeric value for computing the reputation value. For example, node202 can map the routing policy attribute or protocol attribute to anumeric value.

Note that node 202 can compute a reputation value for a face with theparticular name prefix. This is computing a reputation value “pername-prefix, per face.” A different name prefix for the same face may beassociated with different attributes, and thus a different reputationvalue.

Note that node 202 may change the set of attributes assigned to a nameprefix or assigned to a face for a particular name prefix eitherperiodically, on-demand, or at any time. Node 202 can change the set ofattributes when new attributes become available, or can change theattributes (and weight values) when node 202 changes the objective of aname prefix. An administrator may make the changes, or node 202 can makethe changes automatically.

Node 202 may use the set of attributes assigned to a name prefix and/orface to determine attribute values. Node 202 may dynamically compute orupdate the attribute values whenever appropriate, such as when node 202receives a Content Object (e.g., to update latency metrics), or receivesan Interest (e.g., to update the number of times that an Interest isreceived). As another example, node 202 may update the number ofsuccessful signature verifications when it successfully verifies thesignature for a Content Object. Node 202 may update attribute values forother attributes when appropriate.

Node 202 may compute the values of the attributes locally based onhistorical information, such as past traffic data over a period of time(e.g., past 5 minutes, past 20 days, or past one year). Node 202 mayanalyze historical data and quantify attribute values using theperformance of the node for various different namespaces. For example,node 202 may collect and maintain logs and metrics data for a face(e.g., face 216) that node 202 has forwarded Interests to over a periodof time for a namespace “/bbc,” and may compute an attribute value fromthe data.

Each node may normalize its attribute values independent of other nodes,depending on their own local criteria. For example, node 202 maynormalize attribute values based on the highest attribute expected value(e.g., the value encountered). Node 202 may normalize attribute valuesso that higher scores are better, while other nodes may normalize theirattributes so that lower scores are better. A node may normalizeattribute values such that it will compute a reputation value betweenany set of values (e.g., in the range [0,1]).

Node 202 may also assign a weight value to each attribute independent ofhow other nodes assign their weights. Node 202 may assign weight valuesfor each attribute on a “per name-prefix,” “per face,” or “pername-prefix, per face” basis. That is, node 202 can assign a set ofweight values to attributes for a name prefix. It can also assignanother set of weight values to attributes for a face. Node 202 can alsoassign yet another set of weight values to a face for a particular nameprefix. Alternatively, node 202 may use the same set of weight valuesfor all namespaces and faces at a node.

Node 202 may also assign weight values at different hierarchical levelsof a namespace. For example, node 202 may associate the name prefix“/cnn” with one set of weight values, and node 202 may associate thename prefix “/cnn/headlines” with another set of weight values.

Node 202 may set weight values based on criteria determined fromavailable local resources, policy requirements, and/or any otherconstraints. Node 202 can evaluate the criteria and constraints toautomatically (e.g., without human intervention) set or updateattributes and weight values that satisfy the criteria and constraints.Node 202 may reassign new weight values according to the importance ofattributes, and compute reputation values according to the new weightvalues. For example, if response time is important, node 202 mayincrease the weight value of the latency attribute, and compute newreputation values. As another example, node 202 may adjust weight valuesto maximize the use of available resources and avoid underutilization ofresources, while staying within maximum usage thresholds. Node 202 candynamically update attribute values and update the weight values duringthe same process.

Node 202 can examine historical logs and metrics data to determine theoptimal weight values that can make optimal use of resources (e.g.,bandwidth and available cache) at different points in time. For example,over a period of time, node 202 may determine that an attribute, such asavailable bandwidth, is not critical for namespace “/bbc/headlines.”Node 202 may then reduce the weight value of the available bandwidthattribute for namespace “/bbc/headlines.” If bandwidth is importantbetween 5 PM and 7 PM, node 202 can increase the weight value foravailable bandwidth during those hours. Note that node 202 can determinewhether bandwidth is more critical during certain hours by examininghistorical information detailing how traffic flows through the node'sfaces over different periods of time.

As another example, two Internet service providers (ISPs) may have acontract or tie up limiting the number of Interest messages between thepeak hours of 5 PM and 7 PM to x Interests. Node 202 may dynamicallyadjust weight values during the peak hours of 5 PM to 7 PM to limit thenumber of Interest messages and re-adjust the weight values back totheir original values after 7 PM.

Node 202 can set the weight values to achieve an objective of anamespace. This allows a node to forward Interests or cache ContentObjects based on the objectives or goals associated with the namespace.For example, if routing policy is unimportant, node 202 may set w₃=0where w₃ is the weight value for a routing policy attribute. Routingpolicies include, for example, restrictions on routing between nodesduring certain time periods or restrictions on traffic load or types oftraffic to some portions of the network. As another example, low latencyis important for a good viewing experience with streaming video.Therefore, node 202 may set w₁=100 where w₁ is the weight value for alatency attribute. If security is paramount, such as when accessing abank account online, then node 202 may set w₂=100 where w₂ is the weightvalue for a signature verification attribute.

As another example, high bandwidth and low latency can be importantfactors for a namespace associated with streaming video (e.g.,“/netflix/video”). In contrast to other namespaces (e.g.,“/citibank/savings”), the likelihood that a Content Object signaturewill verify successfully is not as important for streaming video. Thus,for the namespace “/netflix/video,” node 202 can increase the weightvalues for latency and bandwidth attributes, and decrease the weightvalues for signature verification attributes. As another example,“/cnn/videos” name prefix may involve different constraints than“/cnn/headlines” name prefix, and node 202 may also adjust the weightvalues to emphasize low latency and high bandwidth for “/cnn/videos.”

For the name prefix “/citibank/savings,” node 202 may reduce the weightvalues for latency and bandwidth attributes, and increase the weightvalues for the signature verification attribute. This places an emphasison security, since there is a higher likelihood that received ContentObjects will have digital signatures that verify successfully.

The nodes may determine and set the weight values locally. In someembodiments, an administrator may establish the value of the weights.The administrator can initially configure the weight values and thennode 202 can dynamically update the weight values to ensure the localresources are not over utilized or underutilized. The administratorand/or node 202 can change the weight values as their needs change, andcertain attributes become less important while other attributes becomemore important. In some embodiments, an organization may manage a sectorof nodes, and set the weight values for the nodes with a globallydistributed protocol.

Node 202 can compute the reputation value for a name prefix and/or facebased on the attribute values and weight values. In some embodiments,node 202 may compute reputation values for all forwarding rules in thelocal FIB. Node 202 may compute and maintain a reputation value for aname prefix (e.g., “per name-prefix”) or for a face with a particularname prefix (e.g., “per name-prefix, per-face”). After computing thereputation values, node 202 can use the reputation values to makeforwarding decisions. In some embodiments, node 202 may computereputation values for faces that are candidates for forwarding anInterest when node 202 receives the Interest. Node 202 may update thecomputation values each time node 202 receives an Interest or ContentObject. Node 202 may also compute reputation values before deciding tocache a Content Object in its Content Store and/or before determiningwhich cached Content Object from its Content Store it can return inresponse to satisfy an Interest.

Reputation values are dynamic, and can change over time. For example, at12:00 PM, face 214 may have a 50% reputation value, face 216 may have60% reputation value, and face 218 may have 80% reputation value. Node202 may forward an Interest via face 218 because face 218 has thehighest reputation value of 80%. However, 10 minutes later, the networkload distribution may change and network latency for the various facesalso changes. An increased load at a face may also increase the latencyof the face, thereby reducing its reputation value. Face 214 may changefrom the previous 50% reputation value to 80% reputation value, and face218 may change from the previous 80% reputation value to 60% reputationvalue. Node 202 can shift the forwarding of Interests from face 218 toface 214 in response to the changing reputation values and changingnetwork conditions.

Node 202 can also compute reputation values in non-real-time. Forexample, node 202 may cache some or all received Content Objects, andcan periodically run a program through the elements in the cache tore-compute their reputation values. Node 202 can determine which ContentObjects need to be evicted based on their reputation score. Node 202 canthen store the updated reputation values for a name-prefix associatedwith a Content Object or a name-prefix-face combination associated witha Content Object (e.g., the reputation value is particular to the nameprefix and face from which the Content Object was received).

In some embodiments, node 202 may also normalize the reputation value.For example, the normalized value can be in the range [0,1], or in therange [0,100]. The reputation value improves as the value of thereputation value increases, with the highest reputation value being theoptimal score.

FIG. 3 and the associated description below present an introductoryoverview, and each CCN node may perform the individual operations ofFIG. 3 at different times when executing operations of FIG. 4-FIG. 6.

Processing an Interest Using Attribute Values

FIG. 3 presents a flow chart illustrating an exemplary process forreturning a Content Object in response to receiving an Interest, inaccordance with an embodiment of the present invention. When a CCN nodereceives an Interest, the node may return a Content Object from itsContent Store or may forward the Interest to one or more faces. If thenode forwards the Interest, the node may then receive one or moreContent Objects from one or more faces, and returns a Content Object viathe face from which the node had received the Interest.

The node may initially receive an Interest via a face to a neighbor(operation 302). The node may determine whether there is an existingContent Object cached in the Content Store that can satisfy the Interest(e.g., a Content Object with a matching name prefix) (operation 304). Ifthere is such a cached Content Object, then the node may determine areputation value for the Content Object's name prefix (operation 306).In some embodiments, the node can store reputation information alongwith that Content Object in the Content Store. This reputationinformation may include a reputation value, and may include theattribute values and weights that were used to compute the reputationvalue. Hence, while determining the reputation value, the node canretrieve the reputation value it stored in association with the ContentObject, or it can compute a new reputation value using the attributesand/or weights stored in the reputation information. For example, thenode can use weights associated with a given objective (e.g., security)and the stored attribute values to compute the reputation value for thegiven objective. Alternatively, the node can compute the reputationvalue using some weights from the Content Object's reputationinformation and using other weights that are customized for the desiredobjective. As another example, the node can compute an updated attributevalue for the Content Object by replacing some of the stored attributevalues with more recent attribute values associated with the ContentObject's name or name prefix.

The node may determine whether the cached Content Object's name prefixis associated with a reputation value above a predetermined threshold(operation 308). If the reputation value of the cached Content Object isabove the predetermined threshold, the node may return the ContentObject to the requesting node (operation 310). In some embodiments, ifmultiple Content Objects from the Content Store can satisfy theInterest, the node can return the Content Object with highestreputation. The node can also update attribute values, weight values,and reputation values at this time.

If the existing Content Object's name prefix is associated with areputation below the predetermined threshold (operation 308), or if thenode is not caching a matching Content Object (operation 304), the nodemay determine one or more faces that the node can use to forward theInterest (operation 312). Since the Content Store does not cache aContent Object with a reputation value that meets the requisitethreshold, the node may forward the Interest to one of its neighboringnodes to obtain another Content Object that can satisfy the Interest.The node can look up the entries in a FIB to find forwarding rules thatmaps a name prefix of the Interest to one or more candidate faces.

The node can then determine a reputation value for the Interestnamespace for each candidate face (operation 314). Each entry in the FIBalso includes the corresponding reputation value. Alternatively, thenode may update the reputation information associated with a candidateoutbound face and/or the name prefix. The node may then select acandidate face based on the reputation values (operation 316). In someembodiments, the node may select a face with the highest reputationvalue, or multiple faces with reputation values above a predeterminedthreshold. The node may forward the Interest via the one or moreselected faces (operation 318).

FIG. 4 presents a flow chart illustrating an overview of an exemplaryprocess for computing a reputation value, in accordance with anembodiment of the present invention.

During operation, a node may initially assign a set of attributes to aname prefix or a face for a particular name prefix (operation 402). Thenode may then determine attribute values for the set of attributesassigned to a name prefix or a face for a particular name prefix(operation 404). The node can assign a weight value to each attribute(operation 406), and computes a reputation value for a name prefixand/or a face based on the attribute values and weight values (operation408).

FIG. 5 presents a flow chart illustrating an exemplary process for usingreputation values to determine how to forward an Interest, in accordancewith an embodiment of the present invention. When a node receives anInterest, the node may determine the faces that are candidates forforwarding the Interest. In some embodiments, the node can determine acandidate face by performing a minimum-prefix-matching lookup (e.g., ina FIB) to obtain a forwarding rule that maps the Interest's name prefixto one or more candidate faces.

The node determines the reputation value of the candidate faces, andchooses one or more candidate faces with reputation values that satisfya predetermined threshold for forwarding the Interest. The node thenforwards the Interest to one or more faces.

In some embodiments, a forwarder and a reputation computation module mayperform the FIB lookup, determine the candidate faces, compute thereputation values for the candidate faces, and choose one or more facesfor forwarding the Interest. Some embodiments may include an additionalforwarding decision-making module that performs the decision-makingfunctions for forwarding Interests. Note that there are equivalentcomponents on each node of the CCN to perform these functions.

As depicted in FIG. 5, the node may initially determine candidate facesfor forwarding the Interest (operation 502). The node can look upforwarding rules in the FIB to determine which candidate faces it canforward the Interest to. For example, the FIB may a forwarding rule thatmaps “/bbc” to faces A, B, and C. Based on the forwarding rule, the nodecan forward an Interest with prefix “/bbc” to any one or more of facesA, B, and C.

The node then determines or updates the reputation values of thecandidate faces (operation 504). The node may access the FIB to add,look up, or update the reputation values of the candidate faces. Thenode may add a reputation value if there is no existing reputationvalue, and/or while adding the forwarding rule to the FIB. The node mayalso periodically compute and store an updated reputation value based onrecent attribute values or weight values for the name prefix orinterface. For example, the node may look up an existing reputationvalue if the corresponding attribute values and weight values have notchanged, or may update the reputation value if a corresponding attributevalue or weight value has changed.

Note that the node generally computes reputation values for forwardingrules in the FIB as “per name-prefix, per face,” meaning that areputation value is associated with a specific name prefix and aspecific face. However, the node may compute some reputation values as“per name-prefix,” so that a reputation value is only associated withthe name prefix and not associated with any face. In some embodiments,the FIB may designate a reputation value as a “per name-prefix”reputation value by entering a zero in the column for the face.

In some embodiments, when processing an Interest, the node need only add(e.g., compute and write), update, or look up reputation values forfaces that are listed with a name prefix of the Interest. For example,if the name prefix is “/bbc” and only the forwarding rules for face A,face B, and face C have name prefix “/bbc” in the FIB, then the nodeonly adds, updates, or looks up reputation values for face A, face B,and face C. An example FIB may include a 65% reputation value for face Cand 60% reputation value for face B and face A. Note that the node neednot compute or look up reputation values for faces that are notcandidate faces. The node need not compute or look up a reputation valuefor a face D if face D is associated with name prefix “/netflix.”

In some embodiments, the node can “collapse” the reputation values sothat the node computes reputation values on a per face basis. That is, aface can have a reputation value (and/or set of weight values andpossibly set of attributes and/or attribute values) that is independentof the name prefix. Alternatively, the node can also associatereputation values with name prefixes with fine-grained granularity orcoarse-grained granularity. The node can associate reputation values(and/or weight values and/or attributes and/or attribute values) withname prefixes at various levels of a namespace hierarchy. For example,the node can associate a reputation value (and/or weight values and/orattributes and/or attribute values) with “/bbc” and another reputationvalue (and/or weight values and/or attributes and/or attribute values)with “/bbc/headlines.”

The node can also classify name prefixes so that the name prefixes of aparticular classification can have the same reputation values (and/orweight values and/or attributes and/or attribute values). For example,name prefixes for various news websites (e.g., “/bbc/headlines” and“/cnn/headlines”) may have the same set of reputation values (and/orweight values and/or attributes and/or attribute values). Also, packettraffic associated with a particular organization may be processed usingthe same reputation value, weight values, attributes, and/or attributevalues. Providing the node with fine-grained control over reputationvalues, weight values and attributes improves performance and increasesthe probability of meeting the objectives associated with a name prefixor content category.

The node may determine which candidate faces have reputation valuessatisfying a predetermined threshold (operation 506). The node maychoose to not forward the Interest to a candidate face that does nothave a reputation value satisfying the predetermined threshold. Forexample, if the predetermined threshold is 60%, the node may choose tonot forward the Interest to a candidate face associated with areputation value of only 40%.

In some embodiments, the node may assign priorities to ingress faces.For example, the node may assign a higher priority to face E than faceD. The node may forward via faces with higher reputation values (e.g.,above a predetermined threshold) the Interests received through faceswith higher priority, and it may forward via faces with lower reputationvalues the Interests received through faces with lower priority. Thenode may forward an Interest received through face E via a face withhighest reputation value for a name prefix of the Interest. For example,if the node receives an Interest with namespace “/bbc/headlines” throughface E, the node forwards the Interest via face C, assuming that face Chas the highest reputation value (e.g., 65%) for namespace“/bbc/headlines.”

The node may then forward the Interest to one or more candidate faceswith reputation values satisfying a predetermined threshold (operation508). In some embodiments, the node may determine that faces withreputation values within a predetermined range are candidates forforwarding the Interest. For example, faces with reputation valuesbetween 65% and 100% can be candidates for forwarding an Interest. Thenode may then forward the Interest to one of the candidate faces, aselection of the candidate faces, or all of the candidate faces. In someembodiments, the node may randomly choose to forward an Interest to oneof the faces.

If the difference in reputation values between two faces is within apredetermined threshold, the node can forward an Interest to both faces.For example, if face A has a reputation value of 60%, face C has areputation value of 65%, and the maximum allowed difference is 6%, thenode can forward an Interest to both faces.

Caching a Content Object

FIG. 6 presents a flow chart illustrating an exemplary process forupdating attribute values, weight values, and reputation values, andusing reputation values to determine whether to cache a Content Object,in accordance with an embodiment of the present invention. As depictedin FIG. 6, when a node receives a Content Object satisfying an Interest,the node may update the corresponding attribute values, weight values,and reputation values stored locally. The node decides whether to cachethe Content Object by comparing the reputation value to a predeterminedthreshold, and may proceed with caching the Content Object if thereputation value is above (or below) a predetermined minimum (ormaximum) threshold. The node then returns the Content Object via a facefrom which it received the Interest.

During operation the node can receive a Content Object satisfying anInterest in the PIT (operation 602). For example, the node may have sentan Interest with a name prefix “/bbc/headlines” via face A. Then, whenthe node receives the Content Object satisfying the Interest from faceA, the node can use this Content Object to satisfy the Interest. In someembodiments, the node may receive multiple Content Objects associatedwith a common name or name prefix via multiple faces. If the nodereceives multiple Content Objects with different reputation values, thenode may store each of these multiple Content Objects with theirrespective reputation information (e.g., reputation values and/orattribute and weight values).

The node may update reputation information, including attribute values,weight values, and reputation values, for each of one or more ContentObjects (operation 604). For example, the node may update a log, whichstores historical performance data, to include a latency based on theround-trip delay between when the Interest was disseminated and when acorresponding Content Object was received. The node may also compute anew average-latency attribute value (and other attribute values) basedon the historical performance data. The node may also adjust the weightvalues to reflect new objectives. After receiving one or more ContentObjects and updating the attribute and/or weight values, the node mayuse the updated attribute data and/or weight values to update reputationinformation for the faces (or for the name or name prefix of the ContentObjects received via the faces) from which the one or more ContentObjects were received. Note that the node can use any customizedcombination of attributes and attribute and weight values to compute thereputation value. In some embodiments, the node can update the attributevalues, weight values, and reputation values at any time, including whenthe node receives an Interest, when the node receives or recomputes newweight values, or periodically during a scheduled automated task.

In some embodiments, the node may periodically sample performance datafrom a subset of Interests and/or Content Objects received via a face,or for a certain name prefix to maintain efficiency. The node may sampleand log (e.g., store) response times for only a select portion of theInterests and Content Objects that it receives to mitigate anyperformance impact due to the overhead of maintaining historicalperformance data and computing up-to-date performance attributes.

The node may decide whether to cache a Content Object based oncorresponding reputation information (operation 606). The node may cachea Content Object if an associated reputation value is above (or below) apredetermined minimum (or maximum) threshold. The node may determinewhether to cache a particular Content Object based on the reputationvalue of the face (or the name or name prefix of a Content Objectreceived via the face) that the node receives the Content Object from.In some embodiments, the node may also determine whether to cache aparticular Content Object based on a reputation value associated with aname prefix for the Content Object itself, independent of any particularface. This reputation value may be, for example, an aggregate ofreputation values for multiple faces from which the node received theContent Object. The node may store the Content Object in a ContentStore, and may also store the Content Object's reputation information,including the reputation value and/or the attribute and weight valuesused to compute the reputation value (operation 608).

The node may then return the Content Object via the face through whichit received the Interest (operation 610). If multiple PIT entries existfor the Content Object's name prefix, the node may return the ContentObject via multiple faces.

In some embodiments, the node can adjust weight values for a name prefixto dynamically adjust how the node determines whether to cache a ContentObject for this prefix. These weight values can be associated with thecache-decision process, and are different than the weight values usedfor determining how to forward an Interest Note that the cache-relatedreputation values can be computed so that a higher (or lower) reputationvalue for a name prefix causes the node to cache Content Objectsassociated with the name prefix. For example, if latency is a decidingfactor for caching content, the node can assign a higher (or lower)weight value to the latency attribute. Also, as the latency increasesfor a name prefix, the node can normalize the corresponding latencyattribute value to increase (or decrease) reputation value. The node maythen cache Content Objects whose name prefix has a reputation score thatis higher (or lower) than a predetermined minimum (or maximum) value.

The node may also use a number of requests received for the name prefixof a Content Object to determine whether to cache the Content Object.For example, if there are more Interests received for “/bbc/headlines”then “/cnn/headlines,” the node can assign a higher weight value to an“Interest-frequency” or “Interest-count” attribute (and/or for otherrelated attributes) to cache Content Objects for name prefixes for whichInterests are received often, and/or in large quantities. This causesthe node to cache Content Objects for the name prefix “/bbc/headlines”more than other name prefixes for which Interests arrive less often.This improves the response time when the node receives “/bbc/headlines”in the future.

As another example, the node and/or an administrator may adjust a weightvalue for a “verification-success” attribute (and/or for other relatedattributes) to emphasize the importance of signature verification whencaching Content Objects. If the node receives a particular ContentObject from a face that has a low success rate for signatureverification (e.g., only successfully verifies 20% of the signatures),the node may not cache the Content Object after determining that thereputation score for the face is below the minimum score required forcaching the Content Object. However, the node may choose to cache aContent Object received from a face that has 80% signature verificationsuccessful rate.

The node can also evict Content Objects from the Content Store based onthe reputation value associated with each Content Object or associatedname-prefix. For example, the node can re-compute a reputation value fora cached Content Object based on recent attribute values for the facefrom which the Content Object was received (e.g., using attribute valuescomputed after the Content Object was cached). However, if the newreputation value is below a predetermined minimum value (e.g., due to areduced verification-success attribute for the face), the node canremove the Content Object from the Content Store.

As another example, the node may first cache a Content Object via a facewith a reputation score that is slightly above the minimum thresholdvalue. However, if the node receives a Content Object with the same namevia a face with a higher reputation value, the node may evict the cachedcopy of the Content Object, and may store the recent Content Objectreceived via the face with a higher reputation value. Note that theeviction operation does not interfere with the runtime forwarding ofInterests or Content Objects.

In some embodiment, the node may have forwarded an Interest via multiplefaces to solicit multiple candidate Content Objects for the Interest.Then, during operation 602, the node may receive multiple ContentObjects via multiple faces, such that any of these Content Objects canbe used to satisfy an Interest. The node may wait for a predeterminedamount of time (e.g., an Interest's timeout period) to receive and cachemultiple Content Objects. The node may choose to cache and/or return aContent Object received through a face with the highest reputationvalue. For example, the node may forward an Interest via face B when thereputation value of face B is 60%, and forward the same Interest viaface C when the reputation value of face C is 65%. When the nodereceives a Content Object through face B, the reputation value of face Bmay have dropped to 20%, but the reputation value of face C may remainat 65%. Since the reputation value of face B has dropped to 20%, it isnow below a predetermined threshold of 50% reputation value. The nodemay choose to not return the Content Object received through face B, butinstead wait a predetermined amount of time to receive a Content Objectvia face C. If the node receives the Content Object via face C, the nodecan return this Content Object to satisfy the Interest. If the Interesttimes out, the node may return the Content Object from face B to satisfythe Interest as there are no other options.

Exemplary FIB with Reputation Values

FIG. 7 presents a block diagram illustrating an exemplary FIB 700 withreputation values, according to an embodiment. Column 702 stores entriesfor one or more name prefixes (e.g., a content name, and/or name prefixor path), and column 704 stores an associated reputation value for agiven namespace. Column 706 stores an associated face for the namespace.

As depicted in FIG. 7, there are five example forwarding rule entries inFIB 700. For example, the namespace “/bbc” is mapped to faces A, B, andC. The name prefix “/bbc” at face C has a reputation value of 65%, whilethe name prefix “/bbc” at either face A or face B has a reputation valueof 60%. The namespace “/cnn” is not mapped to any face. The FIB entryfor the name prefix “/cnn” has number zero in face column 706 toindicate that there is no face for the namespace. However, the node cancompute a reputation value for the name prefix “/cnn” without regard toa face. Hence, reputation value column 704 for the “/cnn” entry canspecify a reputation value of 60%. The FIB entry for name prefix“/netflix” specifies that name prefix “/netflix” is mapped to a face D,and that “/netflix” at face D has a reputation value of 50%.

FIG. 8 presents a block diagram illustrating an exemplary Content Store800, according to an embodiment. Column 802 stores the namespace of aContent Object. Column 804 stores a reputation value of the ContentObject. Some embodiments may also include a column 806 storing anidentifier indicating a face that the Content Object was receivedthrough.

As depicted in FIG. 8, there are three Content Objects in Content Store800. A node may compute and associate a reputation value with eachobject in Content Store 800. For example, Content Store 800 mayassociate a reputation value of 60% for a Content Object with a nameprefix “/bbc/headlines” received via a face B, and may associate areputation value of 50% for a Content Object with a name prefix“/Netflix/video” received via a face D.

The Content Store may also include a number zero in “face” column 806 toindicate that the reputation value is an aggregated value. For example,the Content Store may associate a reputation value of 60% with a ContentObject with name prefix “/cnn/headlines” whose reputation score wascomputed based on historical data from multiple faces (as indicated by anumber zero for the face identifier).

FIG. 9 illustrates an exemplary apparatus 900 that facilitates strategicforwarding and caching using reputation values, in accordance with anembodiment. Apparatus 900 can comprise a plurality of modules which maycommunicate with one another via a wired or wireless communicationchannel. Apparatus 900 may be realized using one or more integratedcircuits, and may include fewer or more modules than those shown in FIG.9. Further, apparatus 900 may be integrated in a computer system, orrealized as a separate device which is capable of communicating withother computer systems and/or devices. Specifically, apparatus 900 cancomprise a reputation computation module 902, a PIT 904, a FIB 906, aforwarder 908, a Content Store 910, a communication module 912, and aforwarding decision-making module 914.

Reputation computation module 902 can compute and update reputationvalues either periodically or on-demand (in near real-time). A node canmaintain PIT 904 to keep track of pending Interests, and can update PIT904 when it receives a new Interest or when an old Interest is satisfiedor times out. PIT 904 stores entries for Interests that are to bematched against incoming Content Objects, and each entry is removed whena match is made, or when an Interest times out. FIB 906 is a forwardingtable that contains information for the node to determine to whichneighbor node or nodes an Interest needs to be sent.

Forwarder 908 forwards Interests and/or packets on the network.Forwarder 908 performs functions that include deciding to which faces itwill forward an Interest based on reputation values, and updatingreputation values and attribute values when a node receives an Interestor a Content Object. Note that in some embodiments, apparatus 900 mayinclude additional modules that perform some of the individual functionsof forwarder 908, and embodiments of the present invention are notlimited to the modules described herein.

Content Store 910 can store Content Objects that apparatus 900 hasreceived via one or more faces. In some embodiments, communicationmodule 912 can receive a packet. Apparatus 900 may include forwardingdecision-making module 914, which performs functions including decidingwhich faces apparatus 900 can use to forward an Interest based on areputation value. Forwarding decision-making module 914 can also decidewhether to cache Content Objects based on an associated reputationvalue.

Computer System

FIG. 10 presents an exemplary computer system for using reputationvalues to facilitate strategic forwarding and caching, in accordancewith an embodiment of the present invention. As described with respectto FIG. 1, CCN devices can be any type of a computing device, includingmobile computing devices, such as a laptop computer, a tablet or slatecomputer, a smartphone, or a personal digital assistant (PDA), or astationary computing device, such as a desktop computer, an Internetserver, or a home media server. FIG. 10 illustrates an example of such acomputing device.

In FIG. 10, a computer and communication system 1000 includes aprocessor 1002, a memory 1004, and a storage device 1006. Storage device1006 stores programs to be executed by processor 1002. Specifically,storage device 1006 stores a reputation computation module 1008, a PIT1010, a FIB 1012, a forwarder 1014, a Content Store 1016, acommunication module 1018, and a forwarding decision-making module 1020,as well as other applications, such as applications 1022 and 1024.

During operation, reputation computation module 1008, PIT 1010, FIB1012, forwarder 1014, a module to facilitate caching in Content Store1016, and forwarding decision-making module 1020 are loaded from storagedevice 1006 into memory 1004 and then executed by processor 1002. Whileexecuting the program, processor 1002 performs the aforementionedfunctions. Computer and communication system 1000 is coupled to anoptional display 1026, keyboard 1028, and pointing device 1030.

The methods and processes described in the detailed description sectioncan be embodied as code and/or data, which can be stored in acomputer-readable storage medium as described above. When a computersystem reads and executes the code and/or data stored on thecomputer-readable storage medium, the computer system performs themethods and processes embodied as data structures and code and storedwithin the computer-readable storage medium.

Furthermore, the methods and processes described below can be includedin hardware modules. For example, the hardware modules can include, butare not limited to, application-specific integrated circuit (ASIC)chips, field-programmable gate arrays (FPGAs), and otherprogrammable-logic devices now known or later developed. When thehardware modules are activated, the hardware modules perform the methodsand processes included within the hardware modules.

The foregoing descriptions of embodiments of the present invention havebeen presented for purposes of illustration and description only. Theyare not intended to be exhaustive or to limit the present invention tothe forms disclosed. Accordingly, many modifications and variations willbe apparent to practitioners skilled in the art. Additionally, the abovedisclosure is not intended to limit the present invention. The scope ofthe present invention is defined by the appended claims.

What is claimed is:
 1. A computer-executable method comprising:determining, by a computing device, candidate outbound faces forforwarding an Interest by looking up a name or a name prefix of theInterest in a forward information base (FIB) having a respective FIBentry to map the name or the name prefix to a forwarding rule thatincludes a corresponding outbound face for the name or the name prefix;determining reputation values for the candidate outbound faces based onattribute values and the name; selecting a candidate outbound face amongthe candidate outbound faces with one of the reputation values thatexceeds a first predetermined threshold; forwarding the Interest via theselected candidate outbound face; further forwarding the Interest viafirst and second outbound faces; receiving a first Content Object viathe first outbound face; and upon determining that first and secondreputation values for the first and the second outbound faces,respectively, are below and above a predetermined second threshold,respectively: not returning the first Content Object, and waiting toreceive from the second outbound face a second Content Object thatsatisfies the Interest; and upon receiving the second Content Object,returning the second Content Object instead of the first Content Object.2. The method of claim 1, further comprising: computing one of thereputation values for one of the candidate outbound faces by collapsingreputation values associated with multiple name prefixes.
 3. The methodof claim 1, further comprising: determining reputation information forthe name or the name prefix; determining whether to cache the first orthe second Content Object based on the reputation information; andresponsive to determining to cache the first or the second ContentObject, caching the first or the second Content Object.
 4. The method ofclaim 1, further comprising: receiving the first and the second ContentObjects via the first and the second outbound faces; selecting, from thethe first and the second Content Objects, a Content Object with ahighest reputation value; and responsive to determining that thereputation value of the selected Content Object is higher than areputation value of a cached Content Object: caching the selectedContent Object; or returning the selected Content Object via a face fromwhich the Interest was received.
 5. The method of claim 1, furthercomprising: receiving another Interest from an ingress face; performinga lookup in a Content Store to retrieve a cached Content Object thatsatisfies the other Interest, and to retrieve reputation information ofthe cached Content Object; and responsive to determining, from thereputation information of the cached Content Object, that a reputationvalue of the cached Content Object exceeds a second predeterminedthreshold, returning the cached Content Object via the ingress face. 6.The method of claim 1, further comprising: assigning an attribute valueto one or more attributes for a candidate outbound face; assigning aweight value to each of the one or more attributes; computing areputation value for the candidate outbound face for the name prefixbased on the assigned attribute value and the assigned weight value; andstoring reputation information, which includes the computed reputationvalue, the assigned attribute value, and the assigned weight value, inassociation with the candidate outbound face or the name prefix.
 7. Themethod of claim 1, further comprising: receiving a first Interest from afirst ingress face, and a second Interface from a second ingress face;determining that the second ingress face is associated with a higherpriority than the first ingress face; forwarding the first Interest viaa first egress face; and forwarding the second Interest via a secondegress face with a reputation value that is higher than that of thefirst egress face.
 8. The method of claim 1, further comprising: upondetermining that the first and the second reputation values for thefirst and the second outbound faces, respectively, are below and above apredetermined second threshold, respectively: upon not receiving thesecond Content Object within a predetermined time period after receivingthe first Content Object, returning the first Content Object.
 9. Anon-transitory, computer-readable storage medium storing instructionsthat, when executed by a computer, cause the computer to perform amethod, the method comprising: determining candidate outbound faces forforwarding an Interest by looking up a name or a name prefix of theInterest in a forward information base (FIB) having a respective FIBentry to map the name or the name prefix to a forwarding rule thatincludes a corresponding outbound face for the name or the name prefix;determining reputation values for the candidate outbound faces based onattribute values and the name or the name prefix of the Interest;selecting a candidate outbound face among the candidate outbound faceswith one of the reputation values that exceeds a first predeterminedthreshold; forwarding the Interest via the selected candidate outboundface; further forwarding the Interest via first and second outboundfaces; receiving a first Content Object via the first outbound face; andupon determining that first and second reputation values for the firstand the second outbound faces, respectively, are below and above apredetermined second threshold, respectively: not returning the firstContent Object, and waiting to receive from the second outbound face asecond Content Object that satisfies the Interest; and upon receivingthe second Content Object, returning the second Content Object insteadof the first Content Object.
 10. The storage medium of claim 9, whereinthe method further comprises: computing one of the reputation values forone of the candidate outbound faces by collapsing reputation valuesassociated with multiple name prefixes.
 11. The storage medium of claim9, wherein the method further comprises: determining reputationinformation for the name or the name prefix; determining whether tocache the first or the second Content Object based on the reputationinformation; and responsive to determining to cache the first or thesecond Content Object, caching the first or the second Content Object.12. The storage medium of claim 9, wherein the method further comprises:receiving the first and the second Content Objects via the first and thesecond outbound faces; selecting, from the the first and the secondContent Objects, a Content Object with a highest reputation value; andresponsive to determining that the reputation value of the selectedContent Object is higher than a reputation value of a cached ContentObject: caching the selected Content Object; or returning the selectedContent Object via a face from which the Interest was received.
 13. Thestorage medium of claim 9, wherein the method further comprises:receiving another Interest from an ingress face; performing a lookup ina Content Store to retrieve a cached Content Object that satisfies theother Interest, and to retrieve reputation information of the cachedContent Object; and responsive to determining, from the reputationinformation of the cached Content Object, that a reputation value of thecached Content Object exceeds a second predetermined threshold,returning the cached Content Object via the ingress face.
 14. Thestorage medium of claim 9, wherein the method further comprises:assigning an attribute value to one or more attributes for a candidateoutbound face; assigning a weight value to each of the one or moreattributes; computing a reputation value for the candidate outbound facefor the name prefix based on the assigned attribute value and theassigned weight value; and storing reputation information, whichincludes the computed reputation value, the assigned attribute value,and the assigned weight value, in association with the candidateoutbound face or the name prefix.
 15. The storage medium of claim 9,wherein the method further comprises: receiving a first Interest from afirst ingress face, and a second Interface from a second ingress face;determining that the second ingress face is associated with a higherpriority than the first ingress face; forwarding the first Interest viaa first egress face; and forwarding the second Interest via a secondegress face with a reputation value that is higher than that of thefirst egress face.
 16. A computing system, comprising: one or moreprocessors; a memory; and a computer-readable medium, coupled to the oneor more processors, storing instructions that, when executed by the oneor more processors, cause the computing system to perform a methodincluding: determining candidate outbound faces for forwarding anInterest by looking up a name or a name prefix of the Interest in aforward information base (FIB) having a respective FIB entry to map thename or the name prefix to a forwarding rule that includes acorresponding outbound face for the name or the name prefix; determiningreputation values for the candidate outbound faces based on attributevalues and the name or the name prefix of the Interest; selecting acandidate outbound face among the candidate outbound faces with one ofthe reputation values that exceeds a first predetermined threshold;forwarding the Interest via the selected candidate outbound face;further forwarding the Interest via first and second outbound faces;receiving a first Content Object via the first outbound face; and upondetermining that first and second reputation values for the first andthe second outbound faces, respectively, are below and above apredetermined second threshold, respectively: not returning the firstContent Object, and waiting to receive from the second outbound face asecond Content Object that satisfies the Interest; and upon receivingthe second Content Object, returning the second Content Object insteadof the first Content Object.
 17. The computing system of claim 16,wherein the method further includes: computing one of the reputationvalues for one of the candidate outbound faces by collapsing reputationvalues associated with multiple name prefixes.
 18. The computing systemof claim 16, wherein the method further includes: determining reputationinformation for the name or the name prefix; determining whether tocache the first or the second Content Object based on the reputationinformation; and responsive to determining to cache the first or thesecond Content Object, caching the first or the second Content Object.19. The computing system of claim 16, wherein the method furtherincludes: receiving the first and the second Content Objects via thefirst and second outbound faces; selecting, from the the first and thesecond Content Objects, a Content Object with a highest reputationvalue; and responsive to determining that the reputation value of theselected Content Object is higher than a reputation value of a cachedContent Object: caching the selected Content Object; or returning theselected Content Object via a face from which the Interest was received.20. The computing system of claim 16, wherein the method furtherincludes: receiving another Interest from an ingress face; performing alookup in a Content Store to retrieve a cached Content Object thatsatisfies the other Interest, and to retrieve reputation information ofthe cached Content Object; and responsive to determining, from thereputation information of the cached Content Object, that a reputationvalue of the cached Content Object exceeds a second predeterminedthreshold, returning the cached Content Object via the ingress face.